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Transitioning  Domain  Analysis:  An  Industry  Experience 


Abstract:  This  report  provides  an  industry  experience  in  the  planning  and 
execution  of  a  research  project  to  pilot  the  use  of  the  Software  Engineering 
Institute  (SEI)  domain  analysis  methodology  known  as  feature-oriented 
domain  analysis  (FODA).  Supported  by  examples,  experiences,  and  lessons 
learned  from  the  industry  pilot  study  conducted  by  Nortel  in  collaboration  with 
the  SEI,  this  report  addresses  seven  key  areas:  (1)  Nortel’s  motivation  for 
change:  (2)  defining  the  problem  area  and  the  search  for  a  range  of  solution 
possibilities  and/or  approaches;  (3)  obtaining  sponsorship,  participants,  and 
funding:  (4)  development  of  the  project  plan  and  contract;  (5)  implementation 
of  the  project  plan  for  the  pilot  study;  (6)  completion  and  closure  of  the  pilot 
study;  and  (7)  the  transition  and  deployment  of  FODA. 


1  Introduction 

The  creation  of  standards  and  guidelines  such  as  the  Capability  Maturity  ModelSM  (CMM^)1 
for  Software  [Paulk  93a,  Paulk  93b],  ISO  9000,  and  Baldridge  criteria  results  from  the  search 
for  a  means  to  achieve  effective  and  efficient  product  quality  by  industry  and  their  customers. 
Adherence  to  such  guidelines  and  standards  can  provide  industry  with  an  external  motivator 
to  evolve  quality  programs  and  processes  which  meet  customer  requirements.  At  the  same 
time,  cost  containment,  an  internal  industry  stimulus,  is  directly  tied  to  the  goal  of  “providing 
shareholder  value  ”  To  improve  the  quality  of  a  set  of  business  practices,  new  methodologies 
and  technologies  need  to  be  investigated  to  achieve  this  goal. 

1 .1  Purpose  of  the  Report 

This  report  shares  with  the  reader  the  experiences  of  integrating  FODA  into  Nortel  as  a  new 
technology.  FODA,  a  domain  analysis  methodology,  has  been  taught  and  used  in  the  govern¬ 
ment  sectors,  but  it  has  not  been  used  in  an  industry  setting.  Based  on  Nortel’s  experience, 
this  report  provides  lessons  learned  and  guidelines  for  implementing  a  pilot  study  to  research 
and  refine  a  methodology  for  transition  into  its  business  environment.  The  use  of  a  pilot  study 
allows  assessment  of  a  new  technique  to  evaluate  its  merits  in  a  cost-  and  time-effective 
manner. 


1  Capability  Maturity  Model  and  CMM  are  service  marks  of  Carnegie  Mellon  University. 
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The  following  chapters  of  this  report  address  the  seven  key  areas  listed  below: 

1 .  Nortel’s  motivation  for  change 

2.  defining  the  problem  and  investigating  solutions 

3.  obtaining  sponsorship,  participants,  and  funding 

4.  project  plan  and  contract 

5.  implementation 

6.  completion  and  closure 

7.  transition 


1 .2  Intended  Audience 

This  report  is  targeted  towards  individuals  or  groups  that  are  engaged  in  exploring  new  meth¬ 
odologies  or  techniques  for  introduction  into  their  business.  After  discovery  of  a  new  practice 
one  wishes  to  investigate  the  applicability  of  it  with  minimal  investment  in  time,  cost,  and  re¬ 
sources.  One  way  of  doing  this  is  conducting  a  pilot  study. 

The  information  described  is  useful  for  internal  and  external  consultants,  change  agents,  grad¬ 
uate  students,  researchers,  project  leaders  or  managers.  The  background  of  these  users 

would  include  expertise  in  their  field  with  the  ability  to  perform  analysis  in  order  to  change  or 
evolve  the  area  of  interest. 
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2  Nortel’s  Motivation  for  Change 


An  internal  study  conducted  by  Nortel  Research  Triangle  Park  (RTP),  North  Carolina,  in  1993 
concluded  that  Nortel  RTP’s  process  for  managing  and  capturing  product  requirements  was 
one  of  the  areas  which  needed  improvement.  Trillium,  an  assessment  tool  based  on  the  CMM 
and  modified  by  Bell  Canada  and  Nortel  to  include  key  aspects  relative  to  Nortel  customers, 
was  used  to  conduct  this  study.  Nortel  RTP’s  systems  engineering  group,  Global  Services 
Planning  (GSP),  was  given  the  responsibility  to  address  how  to  make  this  process  more  effi¬ 
cient  and  effective  to  meet  business  needs  since  the  primary  focus  of  GSP  is  to  define  product 
and  services  specifications. 

2.1  Overview 

This  document  shares  Nortel’s  experience  and  lessons  learned  while  exploring  the  use  of  a 
new  methodology  to  improve  the  quality  of  its  business  processes.  Specifically,  this  document 
describes  the  research  collaboration  between  Nortel  and  the  SEI  to  trial  the  use  of  domain 
analysis  to  manage  and  capture  software  product  requirements. 

Having  been  introduced  in  the  government  arena,  FODA  was  in  the  process  of  being  intro¬ 
duced  in  the  industry  sector  [Peterson  91].  As  a  telecommunications  company,  Nortel 
provided  the  SEI  an  opportunity  to  investigate  the  use  of  the  FODA  methodology  within  the 
industry.  Since  Nortel  was  willing  to  implement  FODA  on  a  small  scale,  GSP  examined  its  ben¬ 
efits  and  merits  and  could  determine  how  to  tailor  its  use  to  fit  Nortel’s  corporate  environment 
while  minimizing  the  investment  costs  of  this  exploration. 

This  document  also  provides  the  software  engineering  community  with  a  resource  for  conduct¬ 
ing  similar  studies  and  collaborations.  The  intent  is  to  perpetuate  the  discovery  of  new 
advances  in  this  field  of  practice  which  can  be  utilized  by  academia,  industry,  and  government. 

The  steps  followed  by  the  researchers  provide  examples  of  the  best  practices  discovered  and 
activities  to  be  changed  to  better  understand  the  problem-on-hand  and  to  implement  a  similar 
pilot  study. 
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3  Defining  the  Problem  and  Investigating  Solutions 


With  the  process  for  managing  and  capturing  product  requirements  identified  as  an  area  that 
needed  improvement,  the  next  step  required  GSP  to  define  the  current  process  and  investi¬ 
gate  a  solution  to  evolve  this  area  into  an  effective  and  efficient  process. 

3.1  Developing  a  Definition  of  the  Current  Process 

First,  GSP  needed  to  understand  the  current  product  requirements  process.  Since  Nortel  RTP 
was  undergoing  ISO  9000  registration  at  this  time,  documentation  was  being  developed  which 
defined  Nortel  RTP’s  product  requirements  process.  The  documented  process  and  the  Trilli¬ 
um  results  provided  a  starting  point  to  scope  the  problem  definition  of  the  changes  that  were 
required  within  Nortel.  In  addition  to  these,  other  sources  of  internal  information  included  re¬ 
viewing  internal  publications  and  white  papers,  conducting  surveys  and  interviews,  and  relying 
upon  the  authors’  personal  experiences  as  users  of  the  product  requirements  process. 

The  research  to  locate  key  corporate  documents  and  resources  was  intensive  work  since  the 
centralized  libraries  for  processes  and  their  supporting  documentation  was  under  develop¬ 
ment.  However,  the  researchers  gathered  the  necessary  information  through  extensive 
networking  into  several  product  groups  and  across  multiple  Nortel  sites,  including  Ottawa 
(Canada),  Richardson  (Texas)  and  Maidenhead  (United  Kingdom). 

3.2  Investigation  of  a  Solution 

GSP’s  next  step  required  accessing  information  external  to  Nortel  which  included  industry,  ac¬ 
ademic,  and  government  resources.  Not  only  did  GSP  want  to  research  the  experiences  of 
these  external  resources,  but  it  also  wanted  to  learn  from  their  solutions.  Resources  used  to 
support  the  investigation  included  literature  searches,  conferences,  symposia,  and  personal 
conversations.  GSP  investigated  best  practices;  new  techniques  or  tools;  and  new  research 
related  to  requirements  elicitation,  management,  process  definition  and  trends. 

The  annual  SEI  symposium  and  informal  introductions  within  Nortel  provided  GSP  with  the  in¬ 
formation  to  consider  domain  analysis  as  the  methodology  to  be  used  for  improving  the 
product  requirements  process.  One  staff  member’s  affiliation  as  a  visiting  scientist  from  Nortel 
Ottawa  to  the  SEI’s  Application  of  Software  Models  (ASM)  Group  introduced  GSP  to  FODA. 
After  several  meetings  with  the  ASM  Group  and  assessing  other  domain  analysis  methodolo¬ 
gies,  GSP  chose  FODA  to  conduct  the  pilot  study  on  a  software  development  group  within 
Nortel  RTP.  The  ASM  Group  showed  particular  interest  in  a  field  trial  of  their  methodology 
within  industry  since  FODA  case  studies  had  been  performed  within  the  government  sector 
[Cohen  92].  Capturing  customer  requirements  through  domain  analysis  added  interest  to  the 
investigation  since  this  methodology  had  previously  been  used  only  to  gather  software  archi¬ 
tecture  requirements. 


CMU/SEI-96-TR-009 


5 


Finally,  GSP  originated  a  proposal  for  conducting  a  pilot  study  to  investigate  the  use  of  FODA 
for  software  requirements  management  and  capture.  GSP  established  a  collaboration  through 
the  SEI’s  Resident  Affiliate  (RA)  Program2  to  work  with  the  ASM  Group  since  this  was  Nortel’s 
first  encounter  with  the  SEI.  The  RA  program  provided  a  basis  for  conducting  the  study,  a 
foundation  for  Nortel  to  learn  more  about  the  SEI,  and  an  opportunity  for  the  SEI  to  work  with 
the  industry  sector. 

3.3  Lesson  Learned 

Researching  a  problem  and  finding  a  solution  is  intensive  work.  Since  a  lot  of  material  is  pro¬ 
duced,  it  is  important  to  keep  careful  records  of  notes,  resources,  references,  and  contacts.  A 
spreadsheet  is  one  way  of  organizing  this  information.  Once  all  of  the  pieces  of  the  problem 
and  solution  are  collected,  they  must  be  structured  into  a  succinct  description.  This  description 
then  provides  easier  communication  and  learning  to  educate  sponsors,  collaborators,  and  oth¬ 
er  interested  parties.  For  the  pilot  study  proposal,  this  addressed  the  questions:  “What  needs 
to  be  improved,  why,  and  what  can  be  done?” 


InhH  ™lntn9ineerin9KlnS,i!U,e'S  ?esident  Affiliate  Pro9ram  at  Carnegie  Mellon  University  offers  industry 
and  government  sponsorship  of  an  individual  to  work  at  the  SEI  to  learn  software  engineering  technologies  to 
transition  back  into  the  individual’s  organization.  9  i  noiogies 10 
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4  Obtaining  Sponsorship,  Participants,  and  Funding 


Once  the  proposal  had  been  written  for  conducting  a  pilot  study  to  investigate  the  use  of 
FODA,  GSP  needed  to  secure  sponsorship  within  Nortel  for  funding  and  resources  to  support 
the  necessary  research. 


4.1  Proposal  Content 

GSP’s  proposal  required  the  following  four  key  areas  of  information  to  obtain  corporate  spon¬ 
sorship  and  funding: 

•  Need  -  states  the  problem  that  needed  to  be  addressed.  For  GSP,  capturing  customer 
requirements  was  the  problem  realized  through  the  Trillium  assessment  results. 

•  Purpose  -  describes  the  purpose  of  the  research  that  identified  the  expected  impact  on  the 
area  of  investigation.  GSP  targeted  its  research  to  address  Nortel’s  need  to  improve  its 
methodology  for  capturing  and  managing  customer  requirements.  The  purpose  of  the  pilot 
study  was  to  determine  if  FODA  could  improve  the  process  and,  if  so,  in  what  ways. 
Another  purpose  was  to  learn  how  to  introduce  Nortel’s  software  development 
organizations  to  new  technologies  without  creating  massive  disruption  and  incurring 
unacceptable  costs  and  product  turnaround  time  penalties. 

•  Preliminary  plan  -  includes  an  outline  of  the  steps  of  the  investigation,  i.e.,  the  deliverables, 
timeframe  of  the  investigation,  and  resources  required  to  complete  the  plan.  For  the  pilot 
study  proposal,  GSP  identified  the  high-level  steps  of  the  18-month  program  including 
employee  resources,  equipment  requirements,  and  cost  estimates. 

•  Benefits  -  identifies  the  advantages  of  pursuing  the  investigation  to  use  FODA  and  the 
perceived  value  of  the  results.  GSP’s  pilot  study  provided  concrete  steps  to  improve  a  key 
corporate  business  process  and  establish  a  strategic  alliance  with  the  SEI  for  future 
information. 

4.2  Nortel  Executive  Interest  in  Domain  Analysis 

Like  many  organizations,  Nortel  constantly  explores  the  improvement  of  its  business  process¬ 
es  to  create  products  more  effectively  and  efficiently.  Domain  analysis  provides  one  means  of 
improving  the  requirements  and  software  development  processes  through  its  capability  to  for¬ 
malize  the  investigation  of  a  product  definition  [Cohen  92]. 

Historically,  Nortel  has  utilized  domain  analysis  extensively  to  define  software  architecture  re¬ 
quirements,  e.g.,  the  Generic  Services  Framework  (GSF)  project,  which  is  a  large-scale 
object-oriented  (O-O)  reengineering  effort.  The  adopted  development  methodology  for  the 
GSF  project  describes  the  nature  of  object  interactions  and  focuses  on  scoping  and  under¬ 
standing  component  interactions,  which  are  key  elements  of  domain  analysis.  The  strength  of 
their  methodology  is  that  it  details  system  architecture,  but  it  only  captures  customer  require¬ 
ments  indirectly.  However,  FODA  places  emphasis  on  describing  user  interactions  which 
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includes  customers  and  end-users,  as  well  as  cooperating  systems  [Peterson  91]  Many  of 
Nortel’s  product  requirements  are  specifically  defined  in  terms  of  these  interactions. 

GSP  selected  FODA  for  the  domain  analysis  methodology  to  be  used  for  requirements  cap¬ 
ture  and  analysis  because  it  more  closely  captures  the  customer’s  perceptions  of  how  they 

interact  with  the  product.  Also,  the  captured  description  remains  independent  of  the  architec¬ 
ture  that  may  be  implemented. 

Once  the  vice  president  of  the  Systems  Engineering  Department  (SED)  accepted  the  proposal 
and  agreed  to  sponsor  the  funding  of  the  project,  GSP  needed  to  find  a  software  development 
group  to  participate  in  the  pilot  study  (see  Figure  1).  The  director  of  GSP  established  an  agree¬ 
ment  in  principle  with  the  director  of  the  Operator  Services  product  group  to  become 
participants  in  the  study.  The  Nortel  Operator  Services  product  line  organization  retains  the 
responsibility  for  a  group  of  peripherals  and  services  for  its  direct  customers,  i.e.,  the  Regional 
Bell  Operating  Companies  and  the  independent  long  distance  carriers.3 

GSP  provided  the  Operator  Services  Group  with  a  project  plan  which  outlined  the  necessary 
resource  and  time  commitments  before  obtaining  full  commitment  from  the  product  group  to 


Systems  Engineering  Operator  Services 

Division 


Figure  1 :  Organizational  Structure  of  the  Participating  Groups  in  the  Pilot  Study 


4.3  Lessons  Learned  in  Obtaining  Sponsorship  and  Participants 

Obtaining  an  agreement  in  principle  with  a  software  development  group  to  participate  in  the 
pilot  study  was  a  challenge  for  both  parties.  GSP’s  experience  revealed  that  even  though  a 
participant  group  shows  interest  in  the  exploration  of  new  ideas,  the  group  must  give  priority 
to  product  commitments  and  schedules.  This  requires  the  research  group  to  be  sensitive  to 
these  needs.  Also,  a  careful  and  thorough  definition  of  the  study  and  its  resulting  benefits  to 
the  participant  group  needs  to  be  communicated  clearly  and  effectively.  The  participant  group 
needs  to  understand  the  importance  of  time  estimates  (or  schedules)  and  resource  commit¬ 
ments  to  the  study  in  order  to  plan  or  adjust  scheduled  project  deliverables.  Further,  the 
research  group  needs  to  provide  flexibility  in  their  schedule  in  case  of  adjustments  to  the 
scheduled  product  deliverables  by  the  participant  group.  Clear  communication  of  changes  be¬ 
tween  the  participant  and  research  management  becomes  an  important  factor  throughout  the 
project. 
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5  Project  Plan  and  Contract 


Having  obtained  an  agreement  in  principle  by  the  Operator  Services  Group,  GSP’s  next  step 
was  to  agree  on  a  project  plan  and  establish  a  contract  for  resources.  Both  of  these  provided 
the  necessary  foundation  for  full  commitment  to  the  research  project. 

5.1  Project  Plan  for  the  Pilot  Study 

The  pilot  study  required  a  project  planning  session  between  the  ASM  Group  from  the  SEI  and 
the  GSP  and  Operator  Services  Groups  from  Nortel.  Using  several  steps  from  Peter  Block’s 
Flawless  Consulting  [Block  81],  the  plan  included  the  following  elements: 

•  overview  of  the  project 

•  goals 

•  study  prerequisites 

•  project’s  minimum  success  criteria 

•  conditions  for  terminating  the  study 

•  deliverables 

•  schedule 

•  checklist  of  action  items 

The  following  sections  detail  these  elements  of  the  project  plan  for  the  pilot  study. 

5.1 .1  Overview  of  the  Project 

The  overview  provided  a  high  level  outline  of  the  pilot  study  which  was  divided  into  the  three 
phases  listed  below: 

•  FODA  training  and  workshop  -  initial  training  and  experience  in  using  FODA  for  the 
Operator  Services  Group 

•  model  and  database  development  -  the  detail  work  and  design  of  an  object  model  of  the 
FODA  products  and  a  prototype  database  to  store/retrieve  information  using  the  object 
model  structure 

•  FODA  technology  transition  planning  -  the  project  plan  to  transition  the  FODA  methodology 
from  the  SEI  into  Nortel 

5.1 .2  Goals 

During  a  pilot  study  planning  meeting,  the  participating  groups  identified  goals  for  Operator 
Services,  the  SEI,  and  the  Nortel-SEI  joint  effort. 
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Goals  for  Operator  Services  were  as  follows: 


Capture  and  validate  the  current  requirements  process  with  an  end-to-end  team  which 
included  customers,  management,  software  designers,  and  product  testers. 

•  Improve  the  requirements  capture  process  using  the  SEI  domain  modeling  techniques. 

Create  an  environment  for  the  Operator  Services  Group  to  evaluate  new  services 
options  and  reuse. 

Goals  for  the  SEI  were  as  follows: 


Validate  the  use  of  the  FODA  domain  modeling  methodology  in  the  area  of  requirements 
engineering.  It  had  previously  only  been  applied  to  software  systems. 


Demonstrate  SEI  responsiveness  to  industry  needs. 

Develop  a  Nortel  case  study  for  presentation. 

Understand  the  forces  at  work  within  Nortel  which  drive  the  need  for  change. 


Joint  Nortel-SEI  goals  were  as  follows: 


•  Produce  an  Operator  Services  requirements  model  database. 

•  Establish  software  modeling  competence  across  Nortel. 

Develop  a  framework  for  the  models  to  be  used  in  the  software  development  cycle 


Lesson  learned:  These  goals  changed  as  the  research  refined  FODA  and  provided  a  clearer 
understanding  of  how  it  could  be  used  within  Nortel.  The  original  goals,  stated  at  a  high  level 
developed  more  specifically  as  the  pilot  study  progressed.  For  example,  the  goal  to  “improve 
the  requirements  capture  process  using  the  SEI  domain  modeling  techniques”  became  “im¬ 
prove  the  requirements  capture  and  validation  process  using  domain  analysis  elicitation  and 

modeling  techniques.”  During  the  actual  implementation  of  the  pilot  study,  however  these 
goals  were  not  updated. 

As  part  of  the  ongoing  planning  process,  it  is  recommended  that  groups  revisit,  refine,  and  up- 
date  the  goals.  K 


5.1.3  Study  Prerequisites 

The  needs  of  the  research  team  required  direct  communication  among  the  three  groups  (GSP 
0peralor  Services,  and  the  SEI)  in  order  to  perform  the  investigation  most  effectively  (see  Fig¬ 
ure  2).  To  facilitate  communication,  the  FODA  Research  Team  needed  to  know  who  retained 
ownership  of  the  end  deliverables  and  who  the  key  interfaces  from  Operator  Services  and  the 

SEI  would  be.  They  also  needed  to  schedule  time  for  briefings  with  Operator  Services 
management. 
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Figure  2:  Flow  of  Communication  and  Needs  Between 
the  SEI,  GSP  and  Operator  Services 


Lesson  learned:  The  FODA  Research  Team  discovered  that  it  needed  to  hire  contractors, 
purchase  software,  and  set-up  additional  meetings  as  the  pilot  study  was  developed  and  roles 
were  identified  (see  Section  5.2.1,  FODA  Research  Team).  It  was  through  discussions  with 
Operator  Services  and  GSP  management  that  the  FODA  Research  Team  was  able  to  sched¬ 
ule  and  secure  resources.  These  factors  proved  that  communication  of  the  research  group’s 
prerequisites  was  of  utmost  importance  throughout  the  study. 

5.1.4  Project’s  Minimum  Success  Criteria 

The  participating  groups  identified  five  elements  to  be  the  minimal  terms  for  successful  com¬ 
pletion  of  the  study.  These  elements  included  changes  to  the  Operator  Services  requirements 
process  and  plans  for  the  future  use  of  FODA  as  defined  below: 

•  Develop  an  understanding  of  the  current  Operator  Services’  requirements  process. 

•  Identify  a  set  of  common  software  product  functions  to  be  supported  by  the  Operator 
Services  organization. 

•  Develop  a  detailed  model  of  a  service  or  product  to  be  validated  with  a  requirements 
checklist  when  planning  a  service  enhancement. 

•  Gain  committed  plans  for  future  use  and  evolution  of  the  product  models  by  business  line 
management  (BLM),  development  groups,  and  customers. 

•  Develop  tools  and  methodologies  for  the  requirements  process  to  be  applied  to  other 
product  groups. 
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Lesson  learned:  Like  the  goals,  the  minimum  success  criteria  changed  as  the  research  re¬ 
vealed  new  discoveries,  but  the  modifications  were  not  documented.  Thus,  the  originally 
stated  criteria  were  not  met.  Updating  the  minimum  success  criteria  during  the  pilot  study  im¬ 
plementation  proved  to  be  a  necessary  and  beneficial  aspect  of  carefully  monitoring 
procedures  for  benchmarking  and  project  management. 


5.1.5  Conditions  for  Terminating  the  Study 

A  set  of  checkpoints  assessed  whether  progress  was  being  achieved  to  satisfy  the  goals  dur¬ 
ing  the  pilot  implementation.  Some  of  the  conditions  for  termination  of  the  study  included  the 
following: 

•  lack  of  committed  resources 

lack  of  progress  in  achieving  the  minimum  success  criteria 

•  insufficient  development  of  models  and  databases 

•  insufficient  buy-in  to  use  models 

•  no  commitment  to  plan  evolution  of  the  model  database 

Lesson  learned:  The  research  group  received  the  necessary  resource  commitments  at  the 
onset  of  the  pilot  study.  But  only  one  progress  check  was  conducted  to  determine  if  the  study 
was  achieving  the  minimum  success  criteria.  As  a  result,  the  FODA  Research  Team  lost  re¬ 
sources  due  to  product  delivery  commitments.  To  provide  more  effective  planning  and  project 
management,  regular  checkpoint  review  dates  needed  to  be  scheduled  at  the  beginning  of  the 
project.  These  reviews  should  involve  the  research  and  participant  group’s  management. 


5.1.6  Deliverables 

A  list  of  end  products  from  the  research  included  the  following: 

*  d0Purnented  informat'°n  captured  from  the  weekly  iteration  meetings 
during  the  context  analysis  and  domain  modeling  activities 

*  (iws>  p—  d°main 
‘  stoSLtdSn moduli, a3*315386  deS'9ned  USi"9  e*pert  s*stems  <° 

*  S3& ord°oLrn3in1“on  tebase  Pa°ka9eS  “  C°U'd  Support  la^te 

*  Services  requirements  process  -  enhanced  process  for  validating  and 

collecting  product  requirements  based  on  the  use  of  FODA  capabilities  9 

Lesson  learned:  Each  of  the  deliverables  was  successfully  developed  and  used.  The  work- 
s  op  reports  and  domain  models  have  been  used  by  the  IWS  development  group  in  the 
design  of  their  product  to  enhance  robustness,  which  decreased  errors  found  investing  The 
prototype  database  and  tool  reports  have  provided  the  foundations  for  development  of  a large- 


scale  database.  Operator  Services  has  been  repeatably  using  their  new  requirements  process 
for  product  definition. 

5.1.7  Schedule 

A  timetable  of  events,  activities,  and  deliverables  included  details  of  each  activity,  i.e.,  owners, 
participants,  meetings,  and  reviews.  Micro  Planner  Manager4  was  used  to  detail  and  track  the 
project. 

Lesson  learned:  Since  the  pilot  study  had  to  be  extended  from  6  to  10  months  and  because 
IWS  product  milestones  changed,  the  schedule  and  the  activities  had  to  undergo  several  ad¬ 
justments  to  accommodate  demands  on  the  participants. 

5.1 .8  Checklist  of  Action  Items 

A  checklist  to  track  progress  and  adherence  to  schedule  was  developed  for  each  participating 

group  which  included  scheduled  date,  description,  deliverable,  owner,  and  status  for  each  ac¬ 
tion  item. 


Lesson  learned:  The  checklist  that  was  devised  was  too  complicated  and  cumbersome  to 
keep  updated  and  thus  was  not  used  for  the  full  extent  of  the  pilot  study.  A  simpler  version  and 
easier-to-update  format  is  recommended. 

5.1 .9  Overall  Lessons  Learned  from  Project  Planning  Activities 

GSP  found  that  the  actual  exercise  of  documenting  the  detailed  project  plan  was  the  most  im¬ 
portant  activity  of  this  element.  Although  the  research  team  was  embarking  on  a  research 
assignment  that  was  totally  new  to  GSP  and  Nortel,  the  project  planning  exercise  provided  the 
research  group  with  the  structure  to  analyze  the  task  and  break  it  down  into  steps.  Once  this 
occurred,  mutually  agreeable  steps  could  be  identified  and  scheduled. 

The  research  group  noted  some  key  points  to  consider  if  the  assignment  were  to  be  repeated. 
Even  though  not  every  documented  item  in  the  project  plan  was  used  or  tracked,  an  update 

of  the  goals,  minimum  success  criteria,  and  conditions  for  terminating  the  study  would  have 
been  beneficial. 


One  of  the  important  benefits  of  a  documented  plan  was  that  it  provided  a  basis  for  contract 
renegotiation.  At  the  mid-point  of  the  pilot  study,  the  product  schedule  and  deliverables  for  the 
Operator  Services  Group  changed.  In  the  perception  of  management,  this  placed  the  pilot 
study  on  a  critical  path  of  customer  deliverables.  However,  the  research  group  utilized  knowl¬ 
edge  gained  from  detailed  project  planning  to  modify  the  schedule  to  accommodate  these 


Micro  Planner  Manager  is  a  project  management  application  program  copyrighted  by  Micro  Management  Inc. 
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demands  in  a  way  which  permitted  the  key  objectives  of  the  project  to  be  accomplished.  Ba 
sically,  the  process  for  conducting  FODA  that  was  developed  used  two  types  of  meetings 
modeling  and  review  iterations  (see  Figure  3).  Knowing  how  many  meetings  were  required  al 
lowed  the  research  team  time  to  spread  the  same  effort  over  a  longer  time  period. 


Applications 


Figure  3:  Nortel  FODA  Modeling  Process 


5.2  Contracting  Resources 

With  the  project  plan  established,  the  next  step  was  to  define  the  FODA  Research  Team  roles. 
To  fulfill  the  roles,  resources  had  to  be  negotiated  and  contracted  from  the  GSP  and  Operator 
Services  Groups  and  external  agencies.  Further,  special  skills  such  as  tool  research  had  to 
be  contracted  from  internal  Nortel  support  organizations. 

5.2.1  FODA  Research  Team 

As  the  next  course  of  action,  GSP  established  the  FODA  Research  Team  once  the  project 
p  an  was  reviewed  and  finalized.  The  commitment  of  resources  and  their  time  needed  to  be 
accomplished  through  a  formal  internal  contract  process. 

Nortel  requires  its  business  organizations  to  have  interorganizational  contracts  to  provide  ex¬ 
plicit  definitions  of  the  scope  and  extent  of  planned  collaborations  in  order  for  each 
participating  organization  to  clearly  understand  the  expectations  and  responsibilities  of  the 
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other  organization(s)  involved.  This  contracting  style  proved  beneficial  during  the  pilot  study 
when  development  pressures  increased  within  the  Operator  Services  organization.  The  con¬ 
tract  provided  a  baseline  for  renegotiation  of  Operator  Services’  deliverables  and  resource 
availability. 

GSP  wanted  the  FODA  Research  Team  to  consist  of  resources  from  both  the  GSP  and  Op¬ 
erator  Services  Groups  (see  Figure  4).  In  order  to  maintain  management  commitment 
throughout  the  pilot  study,  GSP  felt  that  it  was  necessary  to  ensure  ownership  of  the  project 
resided  not  only  in  GSP,  but  also  in  the  participating  group.  Revealing  this  ownership  through 
resource  allocation  proved  to  be  effective  and  strategically  important  to  maintain  commitment 
and  understand  the  cultures  that  GSP  engaged  to  change.  This  also  strengthened  the  bond 
between  the  groups  and  fostered  an  exchange  of  invaluable  knowledge  for  this  study  and  for 
future  application.  The  Nortel  groups  learned  from  each  other,  and  the  SEI  and  Nortel  grew  in 
the  breadth  of  this  knowledge  through  the  collaboration. 


GSP 

Operator 

Services 

Contractors 

Staff 

Advisor 

Senior 

Engineer 

Docqmen- 

tation 

Specialist 

1 

Systems 

Engineer 

Senior 

Engineer 

Expert 

Systems 

Designer 

Figure  4:  FODA  Research  Team 


Operator  Services  committed  two  senior  software  engineers  to  the  project,  one  with  an  in- 
depth  knowledge  of  the  Directory  and  Operator  Services  product  lines  and  the  other  with 
graphical  user  interface  (GUI)  and  object-oriented  design  expertise.  GSP  assigned  two  re¬ 
sources,  a  staff  advisor  and  a  systems  engineer,  to  the  project.  The  FODA  Research  Team 
hired  two  external  contractors,  a  documentation  specialist  and  an  expert  in  knowledge-based 
systems/database  design. 

This  variety  of  skills  and  responsibilities  provided  for  a  successful  group-facilitated  domain 
analysis  to  emerge.  Although  individuals  took  on  different  roles,  as  required,  the  FODA  Re¬ 
search  Team  instituted  the  following  role  definitions  for  the  project: 
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•  domain  analyst  to  be  responsible  for  model  elicitation  using  the  FODA  methodology. 
Utilizing  available  capture  tools,  the  domain  analyst  created  a  domain  analysis  database. 

•  documentation  specialist  to  be  responsible  for  capturing  meeting  information  and 
producing  the  study’s  documentation 

•  project  coordinator/manager  to  be  responsible  for  project  planning,  scheduling,  etc. 

•  trained  facilitator  to  assist  with  group  facilitation  needs 

•  an  expert  in  the  domain  of  interest,  teamed  with  the  domain  analyst,  to  help  guide 
the  analysis  effort  and  acquire  domain  analysis  skills  to  become  a  domain  analyst 
for  future  projects 

In  addition  to  the  FODA  Research  Team  members,  Operator  Services  identified  a  group  of 
four  to  seven  subject  matter  experts  (SMEs)  with  expertise  in  the  domains  of  interest  to  par¬ 
ticipate  in  the  pilot  study. 

5.2.2  Supporting  Organizations 

The  FODA  Research  Team  required  additional  skills  to  support  the  efforts  of  the  study  and 
contracted  with  Nortel’s  Tools  Group  for  the  needed  skills.  The  research  team  needed  exper¬ 
tise  for  off-the-shelf  software  recommendations  to  support  development  of  the  prototype 
database  into  a  full-scale  database  for  deployment  beyond  the  pilot  study. 

This  pilot  study  was  the  work  of  an  interdisciplinary  team  of  domain  analysts,  subject  matter 
experts  (aka  domain  experts),  documentation  specialists,  and  project  managers,  drawn  from 
a  wide  spectrum  of  senior  designers,  project  managers,  business  line  management,  and  sup¬ 
port  personnel  within  Nortel,  as  well  as  support  from  the  members  of  the  SEI’s  Application  of 
Software  Models  Project. 

5.3  Tool  &  Database  Plan 

In  addition  to  developing  the  FODA  methodology,  the  research  group  designed  and  developed 
a  prototype  database  for  storage  and  retrieval  of  domain  model  information.  The  FODA  data¬ 
base  was  intended  to  be  a  complete  and  consistent  repository  of  domain  information  that  can 
be  accessed  by  a  user  for  learning  about  the  domain  and  for  developing  further  applications. 

The  database  consolidated  the  information  contained  in  various  pilot  study  reports  and  work¬ 
books.  It  was  designed  by  the  domain  analyst,  and  developed  and  maintained  by  the  expert 
system  contractor.  The  database  schema  uses  an  object  model  to  represent  domain  informa¬ 
tion  in  the  form  of  textual  descriptions. 

The  FODA  Research  Team  also  prototyped  the  generation  of  an  HTML-formatted  version  of 
the  information  in  the  database  and  in  various  reports  to  facilitate  hypertext-based  access. 
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5.3.1  Tool  Development 

As  part  of  the  pilot  study,  a  prototype  tool,  called  the  “Model  Editor,”  was  developed  to  trans¬ 
late  the  information  captured  during  the  analysis  meetings  in  an  object-oriented  database.  The 
tool  provides  the  domain  analyst  with  a  graphical  user  interface  to  populate  the  database  in¬ 
teractively  using  screens  for  each  aspect  of  the  FODA  model:  namely,  domains,  features, 
entities,  and  functions.  It  was  implemented  with  Neuron  Data’s  Smart  Elements™,  a  software 
tool  for  developing  GUI-based  object-oriented  and  knowledge-based  applications. 

Lessons  learned:  The  prototype  suggests  several  directions  in  which  domain  analysis  cap¬ 
ture  applications  can  go,  beyond  static  report  generation.  For  instance,  an  application  could 
be  built  which  allows  the  domain  analyst  to  explore  relationships  and  interactions  within  the 
domain,  as  well  as  propose  new  features  and  analyze  their  effect  on  the  operation  of  the  sys¬ 
tem.  The  participant  domain  analysis  team  from  the  Operator  Services  Group  expressed  an 
interest  in  using  the  domain  database  for  tutorial  material.  During  the  pilot  study,  a  set  of  re¬ 
quirements  for  further  tool  development  was  gathered. 

5.3.2  Tool  Study  Report 

Nortel  is  pursuing  options  for  support  of  its  Model  Editor  and  other  tools  beyond  the  pilot  study 
stage.  It  is  frequently  noted  that  effective  domain  analysis  beyond  the  prototype  stage  requires 
tool  support  [Krut  93],  and  this  effort  is  no  exception.  To  that  end,  Nortel’s  Metrics,  Tools,  and 
Analysis  (META)  Group  was  requested  to  conduct  a  tool  study  to  answer  some  of  the  following 
questions: 

•  What  commercial  databases  are  available  that  are  suitable  for  representing  and 
maintaining  large-scale  domain  models? 

•  What  commercial  tools  are  available  that  may  assist  in  building  these  models? 

•  Which  of  the  tools  identified  above  are  recommended  for  use  within  Nortel  as  the  domain 
analysis  toolset? 

•  What  proprietary  tool  development  is  needed  to  fill  the  gaps? 

•  What  are  the  long-term  support,  training,  maintenance  requirements,  and  costs  for 
this  toolset? 

In  summary,  6  database  tools  (ObjectStore,  ONTOS,  GemStone,  POET,  Objectivity,  and 
VERSANT)  from  a  pool  of  21  were  evaluated  for  their  applicability  to  FODA.  Based  solely  on 
the  requirements  given  for  the  tool  study,  VERSANT  emerged  as  the  best  candidate  in  just 
about  every  major  category  evaluated. 

Regarding  outsourcing  the  product  development  of  FODA  tools,  the  following  four  approaches 
were  identified,  based  essentially  on  the  amount  of  effort  that  is  outsourced: 

•  total  outsourcing  with  Nortel  ownership 

•  total  outsourcing  without  Nortel  ownership 
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partial  outsourcing  G'oint  development) 
Nortel  spin-off 


6  Implementation 


With  a  project  plan  and  resources  in  place,  the  actual  pilot  was  ready  for  execution.  The  overall 
implementation  had  the  strategic  goals  to  transfer  FODA  expertise  into  Nortel  and  conduct  a 
full-scale  FODA  analysis  by  the  research  group.  The  technology  transfer  of  the  FODA  meth¬ 
odology  from  the  SEI  expertise  to  Nortel  proficiency  was  done  in  phases.  The  phases  included 
the  following: 

•  the  ASM  Group  demonstrating  the  methodology  by  conducting  an  analysis  of  the  Operator 
Services  current  requirements  process 

•  the  ASM  Group  teaching  FODA  by  giving  a  three-day  workshop 

•  the  Research  Group  developing  FODA  enhancements  and  performing  a  dry  run  of  the 
modified  methodology 

•  the  ASM  Group  providing  consulting  to  the  FODA  Research  Group  Domain  Analyst  durinq 

the  IWS  product  scoping  and  target  domain  selection  “ 

•  the  Research  Group  domain  analyst  conducting  a  full  scale  analysis  on  the  IWS  taraet 

domain  a 

The  following  sections  discuss  the  activities  involved  in  the  pilot  study  implementation  at 
Nortel. 


6.1  Analysis  of  Operator  Services’  Requirements  Process 

The  SEI  conducted  a  one-day  context  analysis  workshop  to  document  the  Operator  Services’ 
current  requirements  process.  The  workshop’s  purpose  was  to  demonstrate  the  methodology 
to  management,  to  explore  its  suitability  for  Nortel’s  business  domains,  and  to  capture  the  cur¬ 
rent  process.  Participants  included  BLM,  marketing,  management,  design,  hardware/software 
groups,  and  customers. 


6.2  Preliminary  Planning  for  FODA  Training  by  the  SEI 

This  was  the  first  training  of  FODA  by  the  ASM  Group  to  Nortel.  GSP  created  a  preliminary 
plan  for  performing  this  detailed  domain  analysis  and  to  evaluate  the  methodology  closer  as 
a  first  step  in  the  pilot  study  with  a  cross  section  of  people  from  the  Operator  Services  Busi¬ 
ness  Unit  and  observers  from  other  parts  of  Nortel.  This  would  be  Nortel’s  first  experience  with 
trialing  FODA  on  a  larger  scale. 


6.3  Domain  Selection  for  Workshop 

Two  senior  domain  experts  from  Operator  Services  visited  the  SEI  to  exchange  information 

PAHA  rninn  firm  ra  tor  U. .  _ _ 
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regarding  Operator  Services  business  domains  and  FODA,  as  well  as  to  review  proposed 

workshop  training  materials  for  the  ASM  Group.  As  a  result  of  these  discussions,  the  senior 
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experts  and  the  ASM  Group  chose  a  preliminary  target  domain,  Automated  Prompt  and  Re¬ 
sponse  Systems,  for  a  planned  three-day  workshop. 

6.4  Three-day  Workshop 

The  SEI  conducted  a  three-day  training  workshop  at  Nortel  using  the  FODA  methodology  to 
analyze  the  Automated  Prompt  and  Response  Systems  domain  selected  in  the  previous  step. 
This  workshop  was  attended  by  Traffic  Operator  Position  System  (TOPS)  management,  BLM, 
marketing,  senior  designers,  and  Nortel  observers. 

6.4.1  Lessons  Learned 

One  of  the  primary  goals  of  the  workshop,  i.e.,  to  prove  the  suitability  of  FODA  for  analysis  of 
domains  pertaining  to  our  lines  of  business,  was  clearly  established.  However,  for  some  of  the 
project  managers  attending,  this  workshop  did  not  establish  that  FODA  provided  an  advan¬ 
tage  over  existing  domain  modeling  requirements  analysis  techniques.  Using  hindsight,  it 
appears  that  the  reason  for  this  was  that  the  unique  characteristic  of  FODA,  its  classification 
and  analysis  of  product  family  capabilities,  is  difficult  to  demonstrate  in  a  short  time.  What  is 
easy  to  demonstrate  is  the  cost  and  time  commitment  necessary  to  invest  before  these  ad¬ 
vantages  can  be  seen  clearly  in  real  examples.  The  Automated  Prompt  and  Response 
Systems  domain  analysis  produced  examples  that  seemed  promising.  However,  they  were 
not  detailed  enough  to  convince  those  present  that  investment  in  further  application  of  FODA 
to  that  particular  domain  was  justified. 

It  is  interesting  to  note  that  immediately  following  the  workshop  there  was  an  opportunity  to 
pursue  a  detailed  analysis  with  external  customers  in  a  domain  directly  related  to  the  work¬ 
shop  domain.  It  was  not  pursued  partly  because  FODA’s  advantages  had  not  been 
demonstrated  at  the  workshop. 

It  became  possible  to  continue  the  pilot  study  only  by  scaling  down  the  scope  of  the  pilot  study 
efforts,  choosing  a  smaller  domain,  and  beginning  over.  This  bypassed  the  objections  of  many 
of  the  project  managers  by  the  choice  of  a  domain  where  buy-in  could  be  obtained. 

Nortel  s  experience  indicates  that  the  tutorial/workshop,  as  originally  presented  by  the  SEI,  is 
not  always  a  very  effective  means  of  obtaining  sponsorship  and  support  for  undertaking  do¬ 
main  analysis  technology  transfer.  Shorter,  individually  tailored  presentations  have  proved 
more  successful.  The  FODA  Research  Team  does  present  FODA  training  materials  in  detail 
before  achieving  initial  buy-in,  and  even  then,  the  training  materials  are  presented  only  to 
those  participants  who  are  interested  in  taking  on  the  domain  analyst  role.  In  this  way,  the 

training  furthers  the  goal  of  technology  transfer  directly,  decoupled  from  the  need  for  achieving 
buy-in.  s 
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6.4.2  Workshop  Report 

Following  the  three-day  workshop,  a  report,  authored  jointly  by  SEI  and  TOPS,  was  issued  to 
present  the  results  of  the  Automated  Prompt  and  Response  Systems  domain  analysis 
[Krut96]. 

6.5  Selection  of  Participant  Group 

As  a  follow-up  to  the  three-day  workshop,  a  pilot  study  planning  meeting  was  held  at  Nortel. 
GSP  consulted  with  Operator  Services  management  to  select  the  IWS  product  domain  for 
conducting  a  full  analysis. 


6.6  Methodology  Enhancements  and  Dry  Run 

As  a  result  of  FODA  experiences  thus  far,  the  research  team  determined  that  several  process- 
oriented  enhancements  to  the  methodology  were  needed  to  ensure  a  successful  technology 
transfer  to  Nortel.  These  enhancements  included  the  development  of  elicitation  questions  to 
ensure  a  consistent  and  verifiable  FODA  application,  and  a  database  schema  for  modeling  a 
product  representation  to  facilitate  reuse.  The  research  team  conducted  a  dry  run  of  these  en¬ 
hancements  by  applying  the  elicitation  questions  to  a  hypothetical  non-software  domain. 

Lessons  learned:  As  a  general  framework  for  representing  knowledge  about  domains  and 
systems  in  a  domain,  FODA  is  well  documented  in  the  government  sector.  However,  the  pro¬ 
cess  steps  required  to  apply  it  in  a  verifiable  and  repeatable  manner  are  not  yet  clear. 
Furthermore,  formalizing  domain  model  reuse  requires  modeling  representation  means  as 
well;  i.e.,  a  machine-readable  notation  is  required.  To  address  these  needs,  the  Nortel  FODA 
Research  Team  developed  a  set  of  elicitation  questions  to  guide  domain  analysts  and  a  data¬ 
base  schema  for  representing  the  modeling  products  in  a  domain  independent  way.  In  other 
words,  the  modeling  products  (features,  entities,  functions,  information  trees,  etc.)  are  repre¬ 
sented  instead  of  the  domains  directly. 

The  elicitation  questions  have  been  applied  in  a  variety  of  contexts  during  the  pilot  study.  By 
this  means,  the  FODA  Research  Team  has  verified  that  using  the  elicitation  questions  produc¬ 
es  predictable  results.  However,  the  detailed  nature  of  the  questions  produces  a  detailed 
analysis.  Further  work  on  the  elicitation  questions  is  needed  to  tailor  the  questions  to  the 
needs  of  the  organization  undertaking  domain  analysis.  The  FODA  Research  Team  has  indi¬ 
cated  the  general  direction  that  this  work  should  pursue  in  another  paper,  Three  Approaches 
to  Domain  Analysis  Using  FODA:  Opportunities  for  Reuse?  In  two  recent  projects,  modifica¬ 
tions  and  subsets  of  the  questions  which  address  the  goals  of  the  organization  directly  were 
used.  In  one  project,  an  information  model  was  used  as  a  vehicle  to  review  new  feature  re- 
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quirements  for  a  product.  The  information  model  was  developed  in  conjunction  with  the 
product  development  group,  and  then  presented  to  a  group  of  developers,  business  line  man¬ 
agers  (who  served  as  customer  representatives),  and  project  managers  responsible  for  the 
product.  The  information  model  was  used  as  a  framework  for  understanding  the  changes  re¬ 
quired,  interdependencies,  and  construction  rules  implied  by  each  of  the  proposed  features. 
The  organization  found  this  exercise  to  be  very  valuable,  but  strictly  speaking,  it  was  not 
FODA.  Yet  the  experience  employed  several  aspects  of  FODA  to  the  advantage  of  the  orga¬ 
nization.  This  is  an  example  of  a  future  use  for  FODA  by  tailoring  its  elements  to  meeting 
particular  business  needs.  Further,  this  demonstrates  the  flexible  nature  of  the  methodology. 

Since  the  pilot  study,  the  FODA  Consulting  Group  (formerly  the  FODA  Research  Team)  has 
continued  to  look  for  ways  to  improve  our  understanding  of  the  methodology  and  our  ability  to 
produce  meaningful  and  useful  analyses.  Recently,  the  consulting  group  began  using  an  in¬ 
teraction  matrix,  such  as  the  one  in  Figure  5,  to  track  interactions  between  domains.  These 
interactions  are  discovered  through  scenario  analysis.  We  have  found  that,  using  this  matrix, 
a  variety  of  context  diagrams  can  be  drawn,  depending  on  the  point  of  view  required.  This  is 
particularly  useful  when  there  are  several  domains  of  interest. 


Customer  Support 
HAV  &  S/W  Development 
Product  Definition 
Vtork  Environment 
Tools 
QMS  Support 
Product-Project  Management 
People  Management 
Contract  Management 
Requirements  Management 
Process  Design  Management 
Configuration  Management 
Education  &  Training 
Documentation 
Strategic  Planning 
\£rifi  cation  &  Validation 


Figure  5:  Domain  Interaction  Matrix  Example 


In  this  diagram,  the  axes  are  labeled  with  the  domains  of  interest  to  Nortel’s  Quality  Manage¬ 
ment  Systems.  The  dots  indicate  instances  of  specific  interactions,  derived  from  scenario 
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6.7  Analysis  of  IWS  Domain  Planning 

During  this  planning  step,  the  FODA  Research  Team  devised  a  detailed  process  for  perform¬ 
ing  a  modeling  meeting  iteration  using  the  elicitation  questions  and  developed  a  schedule  for 
the  detailed  analysis. 


6.8  Management  Briefing 

The  FODA  Research  Team  presented  the  final  pilot  study  implementation  plan  to  the  Operator 
Services  management  team.  The  plan  was  approved  and  appropriate  resource  and  schedul¬ 
ing  plans  were  made.  It  was  necessary  to  adjust  the  deliverable  schedule  for  the  target  domain 
group  to  accommodate  the  time  commitment  required. 


6.9  Briefing  of  the  IWS  Domain 

Prior  to  beginning  the  main  analysis  effort,  experts  from  the  IWS  product  group  performed  a 
walkthrough  of  the  domain  to  facilitate  the  FODA  Research  Team  in  establishing  a  baseline 
understanding  of  it. 

6.10  Kickoff  Meeting  for  the  IWS  Domain  Analysis 

Following  the  SEI  model,  the  FODA  Research  Team  held  a  FODA  tutorial  and  workshop  for 
the  IWS  group.  The  FODA  Research  Team  led  a  basic  FODA  training  session  that  had  been 
revised  to  include  examples  from  the  three-day  workshop  analysis  and,  as  an  extended  activ¬ 
ity,  a  high-level  context  scoping  analysis  of  the  IWS  organization’s  domains.  The  ASM  Group 
was  present  to  provide  consulting  during  the  tutorial. 

6.11  Scoping  Report  Review 

The  FODA  Research  Team  presented  a  report  of  the  preliminary  context  scoping  analysis  of 
the  IWS  domains  for  review  by  domain  experts.  Based  on  the  context  scoping  analysis  of  the 
IWS  Group’s  domains,  the  group  chose  a  target  subdomain,  IWS  Maintenance. 

Lessons  learned:  The  target  domain  chosen  was  one  in  which  a  reengineering  effort  had  re¬ 
cently  been  completed.  Object-Oriented  technology  had  not  yet  been  adopted,  although  the 
relatively  independent  nature  of  the  products  made  it  a  good  candidate  for  domain  analysis. 
However,  there  was  no  perceived  customer  need  for  the  work  to  be  performed.  The  analysis 
was  seen  by  the  participating  development  community  as  an  opportunity  to  begin  the  transi¬ 
tion  to  0-0  tools  and  technology  in  their  design  environment.  It  soon  appeared  that  it  was  very 
difficult  for  the  group  to  think  in  terms  other  than  the  existing  architecture  of  the  systems.  That 
is,  in  a  complex  distributed  and  networking  system,  it  is  easy  to  draw  context  diagrams  and 
structure  charts  of  the  current  architectural  components  identified  with  different  labels.  It  be¬ 
came  a  responsibility  of  the  domain  analyst  to  propose  alternatives  which  suggested  the 
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means  of  discovering  the  underlying  abstractions.  This  suggests  that  additional  work  needs  to 
be  completed  in  the  area  of  understanding  the  extent  of  the  domain  analyst’s  role  in  shaping 

the  content  of  the  analysis,  as  well  as  other  methods  for  fostering  cultural  change  in 
organizations. 

For  comparison  purposes,  Figure  6  presents  two  versions  of  the  structure  diagrams  men¬ 
tioned  above.  The  arrows  indicate  the  correspondences  between  the  layers  derived.  The 
domains  named  in  A  are  instances  of  systems  in  the  domains  named  in  B.  This  transformation 
allowed  an  important  layer  that  was  not  present  in  A  to  appear  in  B,  i.e.,  the  layer  representing 
the  ultimate  customers  of  applications  in  these  domains. 
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Figure  6:  Structure  Chart  Comparisons 


6.12  Pilot  Study  Implementation  Plan,  Revision  I 

The  initial  schedule  was  revised  based  on  changes  in  TOPS  understanding  of  the  time  re- 
qu|red  to  integrate  and  document  modeling  meetings.  The  first  detailed  implementation 
schedule  contained  two  2-hour  analysis  sessions  per  week.  Initially,  the  development  group 
management  agreed  to  this  schedule.  However,  after  trying  to  adjust  their  product  delivery 

:r:leS’;ina9ement  felt  that  tW0  SeSSions  Per  week  cou|d  have  an  impact  on  their  deliv- 
cables  and  thus  requested  only  one  session  per  week.  Therefore,  the  implementation 
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schedule  was  basically  doubled  in  length,  and  the  meetings  were  reduced  to  one  two-hour 
weekly  meeting. 


Lessons  learned:  In  hindsight,  it  appears  that  the  initial  schedule  would  have  been  too  de¬ 
manding  from  several  angles: 

•  It  would  not  have  allowed  enough  time  to  redact  the  session  notes  and  distribute  them  to 
the  participants  in  a  timely  manner. 

•  It  would  not  have  allowed  enough  time  for  reflection  between  sessions. 

•  It  would  have  compressed  the  pilot  study  in  a  way  that  would  not  have  provided  enough 

time  for  the  database  tool  development  and  other  activities  such  as  documenting  the 
process. 

•  It  would  not  have  effectively  used  the  subject  matter  experts  since  it  did  not  take 
into  consideration  the  demands  of  their  contractually  obligated  deliverables. 

When  developing  time  and  scheduling  estimates  for  domain  analysis  projects,  the  FODA  Re¬ 
search  Team  learned  that  it  is  important  to  understand  the  time  constraints  of  the  participant 
organization,  as  well  as  the  need  for  time  to  process  the  elicited  information. 


6.13  Context  Analysis  Meetings  for  Target  Domain 

The  FODA  Research  Team  and  IWS  team  held  eight  weekly  two-hour  modeling  sessions  us¬ 
ing  the  elicitation  questions  developed  by  the  FODA  Research  Team  to  perform  a  context 
analysis  of  the  target  domain. 


Lessons  learned:  In  the  example  set  by  the  SEI,  a  domain  analysis  using  FODA  produces 
two  documents:  a  context  analysis  report  and  a  domain  modeling  report.  However,  this  did  not 
address  some  key  needs  that  existed  throughout  the  Nortel  pilot  study: 

•  ability  to  bring  people  into  the  analysis  effort  during  the  analysis  and  have  an  efficient 
means  of  bringing  them  up  to  speed 

•  ability  to  document  the  process  steps 

•  ability  to  preserve  alternative  interpretations  and  partial  solutions,  i.e.,  a  means  to 

remember  what  had  been  decided,  how  the  decision  was  derived,  and  the  alternatives 
discussed  along  the  way 

•  establishment  of  a  basis  for  review  and  verification 


To  address  these  needs,  the  FODA  Research  Team  developed  the  concept  of  the  analysis 
workbook.  Each  chapter  of  the  workbook  contained  the  results  of  a  modeling  session,  includ¬ 
ing  diagrams,  a  list  of  terms,  open  issues,  and  so  on.  The  analysis  workbook  became  our 
blackboard  containing  the  raw  form  of  all  of  our  modeling  products.  Most  meetings  began  with 
a  review  of  the  previous  meeting’s  chapter  in  the  workbook. 
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The  workbook  concept  presented  some  drawbacks,  however.  Often,  the  material  required  ex¬ 
tensive  explanation  and  interpretation  to  be  comprehensible.  It  became  difficult  for  the 
documentation  specialist  to  know  what  background  material  was  required.  Further,  the  FODA 
Research  Team  discovered  that  during  the  production  of  the  context  analysis  and  domain 
modeling  reports  much  synthesis  and  derivation  of  linking  abstractions  was  not  completed. 
This  suggested  that  some  intermediary  steps,  during  which  this  material  would  have  been  pro¬ 
posed  and  reviewed,  had  been  skipped  during  the  analysis.  The  result  was  an  incomplete  final 
domain  analysis  report  that  was  not  possible  to  review  completely  in  the  time  allocated. 

Perhaps  periodic  analysis  reports  devoted  to  some  portion  of  the  model  representation  (e.g., 
the  information  model,  context  features,  etc.),  rather  than  one  large  report,  would  be  easier  to 
produce  and  review  and  would  address  these  deficiencies  in  the  methods  employed  during 
the  pilot  study.  Furthermore,  the  FODA  Research  Team  explored,  through  the  database  web 
prototype,  strategies  for  digesting  the  voluminous  information  produced.  An  interface  to  the 
database  was  designed  to  automatically  generate  HTML  files  from  it,  using  templates  which 
formatted  and  explained  the  information.  These  files  were  then  made  available  for  viewing  on 
the  corporate  WAN  via  the  World  Wide  Web. 

6.14  Development  of  Prototype  Domain-Capture  Tools 

Several  members  of  the  FODA  Research  Team  undertook  the  development  of  a  prototype  tool 
for  capturing  domain  analysis  using  Smart  Elements™,  a  commercially  available  object-ori¬ 
ented  GUI  and  client/server  application  development  system.  The  tool  was  named  the  Model 
Editor.  An  HTML-based  database  browser  application  was  also  developed. 

Lesson  learned:  The  FODA  Research  Team  attempted  to  do  much  more  in  this  area  than 
was  possible  given  the  time  and  resource  constraints  of  the  pilot  study.  The  prototype  tool  for 
capturing  domain  analysis  was  completed  too  late  in  the  project  to  be  useful  for  the  purpose 
for  which  it  was  designed.  Its  user  interface  is  quite  complex  and  mouse-movement  intensive, 
making  it  physically  uncomfortable  to  use  for  the  long  periods  required.  Persistent  problems 
with  the  underlying  object  model  remain  as  implemented  using  Smart  Elements™.  The  re¬ 
search  group  was  hampered  by  serious  bugs  in  the  Smart  Elements™  development 
environment  and  a  lack  of  vendor  support  during  the  capture  tool’s  development. 

In  spite  of  these  difficulties,  the  tool  effort  was  valuable  in  that  it  provided  a  clear  understanding 
of  the  requirements  for  a  good  domain  analysis  capture  tool,  and  the  knowledge  to  provide 
development  plans  for  contracting  this  work  outside  Nortel.  In  addition,  the  tool  development 

gave  us  a  framework  for  evaluating  and  refining  the  FODA  database  schema  and  elicitation 
questions. 
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6.15  Contract  Renegotiation 

The  IWS  group’s  schedule  changed  and  required  renegotiation  of  the  end  date  for  the  pilot 
study.  Additionally,  the  FODA  Research  Team  recognized  and  addressed  the  need  for  addi¬ 
tional  tool  development  expertise. 

6.16  Domain  Modeling  Meetings  of  Target  Domain 

The  FODA  Research  Team  and  members  of  the  IWS  team  held  13  weekly  2-hour  modeling 
sessions  using  the  elicitation  questions  developed  by  the  FODA  Research  Team  to  perform 
the  domain  modeling  phase  of  the  target  domain  analysis. 

Lesson  learned:  As  the  modeling  meetings  progressed,  the  FODA  Research  Team  discov¬ 
ered  that  it  was  easy  to  become  mired  in  interesting  but  tangential  discussions  of  a  variety  of 
topics  of  interest  to  the  subject  matter  experts  (SMEs).  To  assist  us  in  becoming  more  meth¬ 
odologically  rigorous,  the  research  group  decided  to  shift  the  focus  of  each  meeting  among 
the  three  kinds  of  modeling  that  the  methodology  describes,  i.e.,  information,  feature,  and  op¬ 
eration.  Devoting  each  meeting  to  one  kind  of  modeling  provided,  in  effect,  a  three-session 
“iteration.”  Prior  to  beginning  an  iteration,  a  plan  of  the  aspects  of  the  domain  to  be  covered 
was  presented,  and  the  relevant  elicitation  questions  were  followed  very  closely  during  the 
meetings.  Using  this  procedure,  the  most  solid  and  consistent  modeling  products  of  the  pilot 
study  were  produced.  Figure  7  illustrates  the  general  view  of  the  process  that  emerged  from 
these  discoveries: 


Figure  7:  Model  Iteration 
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This  was  possible  because  we  partitioned  the  elicitation  questions  into  areas  that  correspond¬ 
ed  to  the  parts  of  the  FODA  methodology  named  in  Figure  7. 

It  is  important  to  note  that  this  somewhat  relentless  approach  was  undertaken  late  in  the  pilot 
study.  By  this  time,  a  good  working  relationship  had  developed  between  the  SMEs  and  the 
FODA  Research  Team,  which  made  it  possible  to  risk  changing  our  approach. 

In  an  analysis  project  completed  by  the  FODA  Consulting  Group  after  the  pilot  study  was  com¬ 
pleted,  this  same  approach  was  used  from  the  beginning  of  the  analysis.  It  worked  well  there, 
too.  Because  “sticking  to  the  questions”  during  context  analysis  enabled  us  to  produce  more 
disciplined  results,  we  had  more  confidence  in  the  results. 

6.17  Review  of  Reports 

Context  analysis  report:  The  combined  FODA  and  IWS  Groups  held  two  two-hour  reviews  of 
the  context  analysis  report  for  the  FODA  Research  Team,  SMEs,  and  the  SEI. 

Domain  modeling  report:  The  combined  FODA  and  IWS  Groups  held  two  two-hour  reviews  of 
the  partially  completed  Domain  Modeling  Report  for  the  FODA  Research  Team,  SMEs,  and 
the  SEI. 

Tool  study  report:  The  combined  FODA  and  IWS  Groups  held  a  one-hour  review  of  the  tool 
study  report. 

Final  report:  The  combined  FODA  and  IWS  Groups  held  a  one-hour  review  and  wrap-up  ses¬ 
sion  which  included  a  demonstration  of  the  prototype  domain  analysis  capture  tool  and  HTML- 
based  database  browser  application. 
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7  Completion  and  Closure 


Communicating  achievements  and  completing  steps  was  important  during  the  pilot  study.  This 
proved  to  the  FODA  Research  Team,  management,  and  participants  that  the  pilot  was  pro¬ 
gressing  at  a  steady  pace  even  though  unplanned  activities  developed.  Certain  milestones 
were  chosen  to  signify  their  completion  with  rewards  or  formal  acknowledgments. 

During  the  pilot  study,  there  were  planned  and  unplanned  activities.  The  project  plan  identified 
the  key  milestones  and  dates  that  had  to  be  updated  when  unplanned  work  was  required.  The 
project  planner’s  task  was  to  keep  the  plan  up-to-date  using  the  software  package  Micro  Plan¬ 
ner  Manager.  But  it  was  the  task  of  the  FODA  Research  Team  to  notify  the  project  planner  of 
any  changes.  The  notification  of  changes  was  formally  done  during  weekly  staff  meetings  and 
informally  as  needed. 

The  planned  milestones  of  the  pilot  study  included  the  following: 

•  management  briefing 

•  kickoff  meeting 

•  IWS  group  training 

•  domain  scoping 

•  context  analysis 

•  context  analysis  report  review 

•  domain  modeling 

•  domain  modeling  report  review 

•  final  report 

•  final  report  review 

•  wrap-up  and  what’s  next  meeting 

In  addition  to  the  implementation  of  the  domain  analysis,  the  plan  included  the  following  par¬ 
allel  activities: 

•  documentation  of  innovations  and  discoveries 

•  presentations  (internal  and  external) 

•  article  writing 

•  management  and  participant  updates 

•  development  of  a  domain  dictionary 

•  development  of  the  database  tool 
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•  development  of  database  applications 

•  documentation  of  a  tool  report 

The  study  began  with  a  carefully  laid  out  project  plan  that  spanned  six  months.  However  dur- 
mg  the  course  of  the  study,  several  unplanned  activities  and  changes  occurred.  Unplanned 
ac  ivities  included  the  development  of  a  return-on-investment  (ROI)  analysis  of  the  study  in 

rrn  ?  maP  the  Pr0dUCtS  °f  the  d0main  ana,ySiS  t0  the  products of  Models  Sare 
opment  process,  and  design  and  maintenance  of  a  World  Wide  Web  (WWW)  site  for  the 

2  irri,y' ha  ror  chanse  awer  ,he  ^  wa* 

T°ra°?  k  h  ?  3  nS  P6r  W6ek  W°Uld  have  an  lmPact  the  current  product  de- 

%£££%££. number  of  sessions  was  reduced  10  °"e  -  a"d  »a  p« 

With  all  of  the  planned  and  unplanned  activities  during  the  pilot,  GSP  and  Operator  Services 
management  learned  that  i,  was  important  to  formally  acknowledge  the  compTerion  ofaTe 
stone.  This  was  done  through  a  meeting,  email  notification,  and/or  the  distribution  of  a  report. 

imp'em®ntation  of  a  Pilot  stucJy  was  a  fairly  new  concept  to  Nortel’s  environment  and 
P  H  wTr6  WOrkln9  extra  t,me  t0  Participate,  GSP  and  Operator  Services  management  re¬ 
warded  the  accomplishment  of  activities  and  milestones  to  maintain  interest  and  enthusiasm 
Rewards  included  gift  certificates,  lunches,  and  a  final  celebration. 

T  Trf  UWraP'UP  and  What’S  "ext”  meeting  held  at  the  completion  of  the 
V'  9  sure  t0  the  studV>  a  Presentation  and  discussions  were  held,  covering 

•  brief  history  of  the  pilot 

•  what  the  work  achieved 

•  where  FODA  had  been  used  besides  the  pilot  study  and  what  was  its  future  within  Nortel 

‘  ™gwo<?kSUmma'y  diSCUSSi°nS  by  9,6  partWpa"te  °<  *•  befits  and  the  areas 

•  awards 

•  pizza  lunch 

•  demonstrations  of  the  database  tool 

After  10  months  of  intensive  work,  this  meeting  formally  brought  the  pilot  study  to  closure. 


8  Transition 


Transition  of  the  FODA  methodology  occurred  during  and  after  the  pilot  study.  During  the 
study,  information  about  Nortel’s  experience  with  FODA  was  shared  internally  and  externally. 
After  the  pilot  study  was  closed  at  the  “wrap-up  and  what’s  next”  meeting  and  celebration,  the 
FODA  Research  Team  became  known  as  the  FODA  Consulting  Group  since  the  methodology 
had  been  proven  useful  to  Nortel’s  business.  Even  before  the  pilot  study  ended,  the  services 
of  the  group  were  commissioned.  With  the  FODA  Consulting  Group,  a  strategy  was  developed 
to  transition  the  FODA  methodology  internally  and  externally. 

During  the  pilot  study,  the  FODA  Research  Team  shared  information  by  writing  papers  and 
articles.  These  documents  contained  information  about  project  planning,  TOPS  context  and 
domain  analysis,  Nortel  FODA  process,  tool  support  research,  and  innovations  discovered  by 
Nortel  about  implementing  the  methodology  in  an  industry  setting.  These  documents,  in  turn, 
generated  presentations.  Several  of  these  presentations  were  given  internally  to  Nortel,  and 
others  were  given  at  external  conferences  such  as  the  SEI  Symposium  and  OOPSLA  (Object- 
Oriented  Programming  Systems,  Languages,  and  Applications).  Further,  presentations  and 
articles  have  been  shared  with  the  SEI  and  external  industry.  In  this  manner,  technology  trans¬ 
fer  occurred  as  discoveries  were  found  and  documented. 


Once  the  merits  of  FODA  became  valuable  to  Nortel  business,  the  FODA  Research  Team  was 
contracted  by  Operator  Services  and  Nortel  Quality  organizations  to  perform  analysis  activi¬ 
ties.  The  TOPS  organization  used  FODA  for  validation  of  product  requirements  and  product 
negotiations.  The  Nortel  Quality  group  used  FODA  to  develop  a  context  analysis  of  its  quality 
management  system.  In  the  Operator  Services  case,  they  simply  wanted  to  contract  the  ser¬ 
vices  of  the  FODA  Research  Team  to  conduct  the  domain  analysis.  For  the  Quality  Group, 
they  not  only  wanted  to  perform  a  context  analysis,  but  they  also  wanted  the  FODA  Research 
Team  to  transition  the  FODA  methodology  to  develop  a  core  group  of  domain  analysts.  Thus, 
the  FODA  Research  Team  became  the  FODA  Consulting  Group. 


As  a  key  Nortel  resource,  the  FODA  Consulting  Group’s  mission  is  to  perpetuate  the  transition 
of  domain  analysis  throughout  Nortel  as  a  means  to  decompose  our  complex  systems  into  un¬ 
derstandable  components.  The  methodology  would  be  used  for  software,  architectural, 
network,  process,  and/or  business  systems.  Also,  the  group  will  promote  and  influence  indus¬ 
try  standards  for  domain  analysis  through  external  consulting  and  presentations.  The  goals  of 
the  group  are  to  continue  refinement  and  research  of  the  methodology,  transition  domain  anal¬ 
ysis  and  ensure  proficiency  in  the  new  practitioners,  and  share  best  practices  and  state-of-the- 
art  innovations  in  the  technology  with  the  Nortel  domain  analyst  guild  community. 

As  a  consulting  group,  the  FODA  Group  will  provide  the  following  services: 


domain  analysis  technology  transition  -  provide  training  and  consulting 
to  build  their  own  set  of  skilled,  practicing  domain  analysts. 


to  a  group  in  order 
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sesl  onl  Xn  tL'i  r  Jn  analyS'S  Services  on  a  contractual  basis  for  single 

h^h  level'orohllnf Hofn r  reqU'red  ,n  an  as-"eeded”  capacity  for  customer  negotiations, 
high-level  problem  definition,  requirements  validation,  and  similar  scoping  activities. 

’  tbechnofoSav  thflf  Xanw^SiS  '  9r°UpS  in  assessin9  whether  domain  analysis  is  a 
technology  that  can  aid  in  scoping  the  current  or  perceived  business  need. 

domain  analyst  guild  -  provide  leadership  for  the  formation  of  a  network  of  domain 

cS  h?  tC! SharG  'nnc™at,ons  and  best  practices  in  maintaining  the  highest  quality 
skill  development,  and  provide  opportunities  to  conduct  and  research  new 
innovations  in  the  technology  and  tools. 

The  planned  process  for  transitioning  the  FODA  methodology  to  a  group  of  new  domain  ana- 
lysts  includes  five  steps: 

•  Nortel  FODA  training  workshop 

•  “toy-domain”  practice  exercise 

•  domain  analysis  planning 

•  plan  execution 

•  consultation 


This  process  uses  the  concept  of  “see  one,  do  one,  teach  one.”  The  training  workshop  will  pro¬ 
vide  the  new  domain  analysts  the  opportunity  to  learn  the  methodology  and  observe  a  domain 
analysis.  This  is  the  “see-one”  stage.  The  “toy-domain”  practice  exercise  session  is  a  small- 
scale  domain  analysis  led  by  the  new  domain  analyst  under  supervision  and  advisement  of  an 
experienced  domain  analyst,  thus  the  “do-one”  stage  of  learning.  The  domain  analysis  plan- 

6XeCl!tl.0n  '®  the  new  domain  analyst’s  project  plan  for  implementation  of  the 
dology  in  his  or  her  area.  The  experienced  domain  analyst  will  be  available  for  consult¬ 
ing  during  the  new  domain  analyst’s  application  of  the  methodology  in  the  real  environment 
This  is  the  stage  where  the  new  domain  analyst  will  be  able  to  “teach  one  ” 


9  Summary 


In  today's  fast-paced  and  competitive  business  environment,  industry  is  constantly  looking  for 

ways  to  improve  the  development  and  delivery  of  its  products.  Nortel  shares  this  same  need 

with  the  rest  of  the  business  world.  To  address  this  need,  seven  key  areas  are  identified  to 

scope  the  effort  to  introduce  a  change  to  the  corporation. These  areas  are  described  below: 

1 .  Motivation  for  change:  Based  on  the  findings  of  Nortel  RTP’s  T rillium  assessment, 
the  need  was  identified  and  motivation  generated  to  improve  the  process  for  man¬ 
aging  and  capturing  product  requirements. 

2.  Problem  definition  and  solution  investigation:  The  GSP  department  was  then 
tasked  with  developing  a  definition  of  the  problem  area  and  exploring  a  set  of  so¬ 
lutions.  After  researching  possible  methodologies,  the  use  of  the  SEI’s  FODA  was 
selected  to  trial. 

3.  Obtaining  sponsorship,  participants,  and  funding:  With  interest  from  the  ASM 
Group  at  the  SEI  to  expand  their  application  experience  of  FODA  into  the  industry 
sector,  a  proposal  for  a  collaboration  between  Nortel  and  the  SEI  was  developed 
to  research  the  methodology’s  use.  With  the  proposal  and  internal  corporate  spon¬ 
sorship,  product  group  participation  and  funding  then  had  to  be  located  in  order  to 
conduct  the  research  pilot  study. 

4.  Project  plan  and  contract:  Once  we  had  secured  corporate  sponsorship  and  the 
Operator  Services  commitment  in  principle  to  participate,  a  project  plan  between 
GSP,  the  ASM  Group,  and  Operator  Services  was  required  to  capture  mutually 
agreed-upon  goals,  minimum  success  criteria,  deliverables,  etc.  Next,  resources 
for  the  FODA  Research  Team  and  to  participate  in  the  study  had  to  be  negotiated 
and  contracted.  Further,  the  skills  of  one  of  our  support  groups  to  conduct  analysis 
of  database  tools  had  to  be  contracted  as  well. 

5.  Implementation:  With  the  resources  in  place,  the  next  step  was  to  implement  the 
project  plan  for  the  10-month  pilot  study. 

6.  Completion  and  closure:  Upon  completion  of  the  study,  closure  to  the  activities 
concluded  with  a  meeting  to  share  the  benefits  and  lessons  learned  and  to  reward 
the  participants. 

7.  Transition:  Finally,  with  a  successful  completion,  presentation,  and  documentation 
of  the  results,  the  need  to  transition  the  methodology  to  other  groups  was  request¬ 
ed.  Thus,  the  FODA  Research  Team  was  transformed  to  a  consulting  group  to 
support  the  perpetuation  and  continued  improvement  of  the  use  of  domain  analy¬ 
sis  within  the  corporation. 
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As  part  of  the  collaboration  with  the  SEI,  a  goal  was  to  share  Nortel’s  experience  as  an  industry 
to  transition  a  technology  into  its  environment.  Thus,  this  report  relates  the  steps  taken  and 
lessons  learned  in  exploring  the  use  of  domain  analysis,  in  particular  FODA,  as  an  external 
solution  to  address  the  need  to  improve  Nortel’s  process  for  managing  and  capturing  product 
requirements. 
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